System and method for delay-based congestion detection and connection admission control

ABSTRACT

Systems and methods for performing congestion detection and connection admission control for a communications network utilizing the observed one-way delay of packets transmitted through the network are described. Embodiments of the present invention provide endpoints on the network, which can anticipate congestion accurately enough to prevent packet loss and excess delay while, at the same time, fully utilizing network resources. In one embodiment of the present invention, a communications service provider replaces conventional tandem switches in a public switched telephone network with Internet protocol (IP) tandems. The IP tandem includes a media gateway, which performs congestion admission control for voice over IP (VoIP) communications. When delay in the communications network exceeds a delay threshold, the media gateway may reject the communications request or may route the request over an alternative channel.

RELATED APPLICATIONS

This application claims priority to U.S. application Ser. No. 10/086,315entitled “System and Method for Delay-Based Congestion Detection andConnection Admission Control” filed Mar. 1, 2002, which is incorporatedherein by reference.

NOTICE OF COPYRIGHT PROTECTION

A portion of the disclosure of this patent document and its figurescontain material subject to copyright protection. The copyright ownerhas no objection to the facsimile reproduction by anyone of the patentdocument or the patent disclosure, but otherwise reserves all copyrightswhatsoever.

FIELD OF THE INVENTION

The present invention generally relates to congestion detection in acommunications network. The present invention more particularly relatesto the delay-based congestion detection and connection admission controlin a communications network.

BACKGROUND

Conventional telecommunications providers offer a broad variety ofservices, including both voice and data services. As these providerscontinue to extend their service offerings, they constantly strive tominimize the costs of providing these services. The consolidation ofvoice and data services provides a substantial opportunity for savings.However, the consolidation of these services and corresponding decreasein cost must not come at the expense of the quality in voicecommunications services (referred to herein as “Quality of Service”(QoS)).

Other organizations, such as large corporations, face similarchallenges: As with telecommunications providers, the integration ofvoice and data networks within an organization presents a greatpotential for savings. Conventional separation of private branchexchange (PBX) and Internet/Intranet often involves significant expense.Organizations typically find it more efficient and cost-effective todesign, deploy, maintain, and support a single integrated network thanto support separate data and voice solutions.

Conventional voice systems rely on circuit-based equipment.Circuit-based equipment provides high reliability and scalability,almost universal interconnection, and a tremendous installed base. Incontrast, conventional packet-based telephone systems, such as Internettelephony, often provide limited reliability and scalability. Protocolsconventionally utilized in packet-based networks, such as file transferprotocol (FTP) and hypertext transfer protocol (HTTP), areopportunistic, taking as much bandwidth as is available. Therefore,mixing voice and data in a single, uncontrolled, packet-based network,often results in low QoS due to a variety of factors, such as jitter,packet loss, and excessive delay. Callers recognize the degradation inQoS resulting from jitter, packet loss, and delay as voice distortion,loss of portions of words or sentences, echoes, talker overlap, anddropped calls. A certain amount of delay is inherent in any packet-basedvoice implementation, including a voice over Internet protocol (VoIP)implementation. However, if the total delay is greater than 150-200milliseconds, QoS will be generally unacceptable.

Jitter, caused by variable inter-packet timing, is one source of QoSdegradation in VoIP services. In a converged network in which voice anddata packets are interleaved, normally orderly packetized voice arrivesat disorderly intervals. Conventional systems implement jitter buffersto address the problem of jitter. Unfortunately, the addition of jitterbuffers result in increased delay in the network.

Packet loss occurs when routers begin to overflow during periods ofcongestion, forcing them to drop packets. Conventional systems attemptto account for packet loss in a variety of ways. For example, aconventional system may compensate for lost packets by interpolation,replaying the last packet received to fill in the non-contiguous speech.Interpolation is effective only for a very small number of lost packets.Other conventional systems send redundant information so that theinformation contained in the lost packets may be replaced withinformation contained in successfully transmitted packets. Sendingredundant information results in increased traffic and requires greaterbandwidth and therefore may cause greater delay within the network.Another conventional approach sends redundant packets but utilizes acodec that results in a smaller number of packets and therefore requiresless bandwidth. Although this approach decreases the bandwidthrequirements inherent in sending redundant packets, the approachincreases the delay and reduces voice quality due to coding effects.

QoS degradation may also result from delay. Delay causes two problems:echo and talker overlap. Echo is caused by the signal reflection of thespeaker's voice from the far end telephone equipment back into thespeaker's ear. To eliminate echo, conventional systems may implement anecho canceller. These are active devices used by phone companies tosuppress positive feedback (singing) on the phone network. They work bypredicting and subtracting a locally generated replica of the echo basedon the signal propagating in the forward direction. To eliminate talkeroverlap, a VoIP system must reduce the total delay experienced duringthe VoIP call.

Delay includes the time necessary to collect a packet or frame of voicesamples to be transmitted, to code and packetize the collected packets,and to transmit the resulting packets over the physical network. Delayresults from several sources, including processing delay, queuing delay,transmission delay, and propagation delay.

Because of the degradation that can affect voice communications in apacket-based network and because of the complexity and cost ofconverting existing circuit-based systems, telecommunications providershave been slow to implement packet-based networks for the transmissionof voice. Large traditional voice carriers are just beginning to mergetheir existing Public Switched Telephone Networks (PSTN) with their datanetworks using Voice over IP (VoIP) or Voice over Asynchronous TransferMode (ATM). But the carriers understand that without acceptable QoS,callers will avoid VoIP.

In order to both provide this voice quality and to begin merging thePSTN with the data network, the carrier must provide a level of QoSwhich provides low loss and a reasonable delay for the RTP voice packetsin the IP core, and at the same time provide, as a minimum, best effortservice for data. In addition to best effort service for data, thecarrier may wish to provide other levels of QoS for other types ofcommunications, include video and fax.

Several conventional approaches exist for maintaining QoS in amixed-service packet network. These approaches include (1) usingdifferentiated levels of priorities,.wherein the voice packets receivethe highest priority and the data packets receive a lower priority; (2)reserving a path through the network across which the communication cantraverse; and (3) performing endpoint or connection admission control.While each of these approaches has its advantages and disadvantages,none provides both a simple, and at the same time, effective means ofensuring QoS for VoIP communication.

One of the simplest conventional approaches for maintaining QoS for VoIPis through the use of differentiated services, assigning differentpriorities for the real-time packets containing the VoIP packetsrelative to other packets in the network. Traditional IP networks useNative IP Forwarding (NIF). A router determines a packet's next hoproute by the finding the longest match of the destination IP addresswith a prefix in the routers forwarding table. At the destination pointof each hop, a router reexamines the IP header for the destination IPaddress and performs the longest match on it's own forwarding table todetermine the next hop. This process repeats hop by hop until the packetreaches its final destination. Note that with NIF, the routing table isthe only state information processed and maintained in the router.

In the DiffServ model, packets entering a network domain are classifiedand marked with a DiffServ code point (DS code point) according to theirrequirements for Per Hop Behavior (PHB). The PHB is a forwardingbehavior that represents queuing and servicing disciplines in therouters. PHBs provide a means of allocating bandwidth and buffersaccording to the relative requirements of the packets being transferredacross the network. Packets are grouped into classifications, and allpackets in a classification receive the same treatment. The keycharacteristic of DiffServ is that classification and treatment arerelative. No reservations are made, and thus one classification mightreceive higher priority relative to other classifications to reducedelay. Another classification might get better treatment relative toother classifications to reduce loss. Ultimately a limited set ofresources is divided among the various classifications, and, if trafficis excessive, loss or excessive delay may occur. However, DiffServ hasthe advantage of not requiring the processing and storing of additionalstate information needed by Multi-protocol Label Switching (MPLS)(described below).

Another approach for ensuring QoS for VoIP is to set up resourcereservations in routers across the IP network. The QoS requirement maybe expressed in the form of bandwidth, delay, or jitter, or may involvespecifying an explicit route across the network. This approach may beimplemented using Multi-protocol Label Switching (MPLS) with some typeof bandwidth reservation capability.

MPLS is the most popular standard of label-based forwarding. Thefoundation for label-based forwarding is Forwarding Equivalency Class(FEC). An FEC is assigned as a packet enters the network and can bebased on information gleaned from the packet header includingdestination IP address or on information not available in the headersuch as the ingress port. A Label representing the FEC is pre-pended toeach packet, and subsequent forwarding decisions are based on theseLabels without examining the packet header at each hop. In practicalterms, at each hop, rather than examining the destination address in theheader, the Label is examined and used as an index to a table thatcontains the next hop to which the packet should be forwarded. Allpackets in an FEC are treated equivalently as they are forwarded acrossthe network. This is similar to switching in an ATM or Frame Relaynetwork in which a Virtual Path Identifier/Virtual Circuit Identifier(VPI/VCI) or Data Link Connection Identifier (DLCI) identifies aPermanent Virtual Circuit (PVC) or Switched Virtual Circuit (SVC). Theforwarding decision is accomplished by a table lookup in the switchusing the VPI/VCI or DLCI along with the ingress port. In an ATM orFrame Relay network, the entries are placed in the table when PVCs orSVCs are established either by signaling or using a network managementsystem. In MPLS, these table entries are placed using a reservationprotocol such as RSVP or CR-LDP, which are described below. The additionof these switching tables in routers represents a second form of stateinformation that must be processed and maintained in addition to therouting tables associated with NIF.

In MPLS a label distribution protocol is used to distribute the labeland associated next hop information to Label Switching Routers (LSRs)throughout the network. Other information may also be distributed andcontained in these tables as well. There are two protocols that havebeen designed to perform this function, Label Distribution Protocol(LDP) and Resource ReSerVation Protocol (RSVP). LDP was originallydesigned to distribute labels to LSRs but is in the process of beingextended to make resource reservations. The extended form of LDP iscalled Constraint based Routing—LDP (CR-LDP). RSVP was originallydesigned to make resource reservations, but has been extended to performlabel distribution. The extended form of RSVP is called RSVP—TrafficEngineering (RSVP-TE). Both CR-LDP, and RSVP-TE perform a signalingfunction that enables some form of Quality of Service (QoS) across MPLS.This signaling reserves resources, which are essentially router queues.These routing queues ultimately represent bandwidth along routes in thenetwork, and this reserving of bandwidth for a particular FEC enablesQoS. If insufficient resources are available to provide QoS for aparticular call, the connection is refused. This is called connectionadmission control (CAC).

The advantage of this approach is that the reservations are not relativeto other traffic on the network as in the case of DiffServ, but are muchcloser to being guaranteed. One of the problems with this approach isthat implementing RSVP-TE or CR-LDP in high-speed core routers requiresthese routers to process and maintain state information for the labelswitching tables and reserved bandwidth. Building high-speed corerouters with these capabilities is complex and very expensive. Also,these capabilities need to be implemented in every router in thenetwork. This violates one of the principles of TCP/IP, which is toprocess and maintain a minimum amount of state information in the core,keeping the core fast and simple, while CPU intensive tasks are pushedto the edge. Scalability is a problem as well, since at least in itssimplest form, a reservation has to be made for each call originatedacross the network. In order to avoid this, tunnels can be reserved andcalls aggregated into these for transport across the network. This toohas its problems in that it makes the process even more complicated andincreases the difficulty in fully utilizing resources in the network. Italso still requires the core routers to process and maintain theadditional state information for the label switching tables and reservedbandwidth.

Another alternative approach is to provide Endpoint or ConnectionAdmission Control (CAC). Traditional PSTNs rely on local switches toperform this CAC function when the network is too busy to process acall. A CAC approach in a packet-based network could rely on a variationof the reservation approach discussed above in which an error code isreturned if the attempt to create a reservation is unsuccessful. Uponreturn of the error code, the phone could emit a busy signal.

An alternative CAC approach maintains a simple core IP network andprovides a means for the edge devices to perform CAC. Under such anapproach, a packet stream requests service from a network edge device,such as a media gateway, and the device includes a means to detectimpending congestion in the IP core. The device either accepts orrejects the request based on the congestion state. This method wouldpush congestion control from the core to the edge and thus simplify thejob of the core routers because it requires no support from the core IProuters; the core routers do not process or maintain state informationother than traditional routing tables.

Several conventional methods for performing CAC in a packet-basednetwork exist. In one method, the routers use congestion marking.However, this method requires more functionality be added to the router,increasing the complexity of the core routers. Another method utilizespacket drops to determine congestion. But for voice applications, theobjective is to avoid congestion before drops occur.

Another conventional method is to use a black box approach to congestionavoidance with implicit feedback based on increased delay. However,conventional methods of this type use window-based flow control for eachindividual user. Also these conventional methods assume deterministicdelays and fail to examine the effects of stochastic delays experiencedin an actual network. In addition, these conventional methods utilizeround-trip delay rather than one-way delay.

A further conventional method utilizes probing packets. Endpoints, suchas media gateways or other hosts, probe the network to detect the levelof congestion. The endpoint admits connections only if the level ofcongestion is sufficiently low. To accurately determine the congestionof the network, the endpoint sends probe packets at the data rate VoIPcall will require and records the resulting level of packet losses,jitter, or other congestion indicator. For example, in one conventionalapproach, the probe packets are sent in a DiffServ code point that is alow priority FEC. The data, which requires the QoS, is placed in thehigh priority FEC.

Although a CAC method based on probing may accurately measurecongestion, the probing and feedback phases slow down the admissiondecision significantly. Probing causes a delay while the probing packetis sent and either feedback is received or a timeout period expires.This delay creates a significant setup delay for the VoIP call, on theorder of seconds, and VoIP applications will not tolerate such longset-up delays.

In another conventional CAC method, the endpoint attempts to determinethe amount of bandwidth a specific communication will require and thenattempts to determine if the required bandwidth is available on thenetwork. For example, the patent to Hiroyuki Yokoyama, et al., U.S. Pat.No. 6,324,166, describes a call setup control apparatus, whichdetermines the amount of bandwidth consumed by current calls, comparesthat amount with the available bandwidth, and accepts or rejects callrequests based on the comparison. And the patents to Patrick Droz, U.S.Pat. No. 6,292,466, and to Gyeong-Seok Kim, U.S. Pat. No. 6,215,768,describe similar systems and methods. Also, the patent to Sari Saranka,U.S. Pat. No. 6,314,085 describes a similar method for performing CACbased on the probability of cell loss given a known capacity. Utilizingestimated bandwidth requirements to perform CAC is relativelyineffective because the differing coding schemes used to transmit voiceover packet networks cause great difficulty in accurately predictingvoice bandwidth requirements.

SUMMARY

The present invention provides systems and methods for performingcongestion detection and connection admission control for acommunications network, utilizing the observed one-way delay of packetstransmitted through the network. Embodiments of the present inventionprovide endpoints on the network, which can anticipate congestionaccurately enough to prevent packet loss and excess delay while, at thesame time, fully utilizing network resources.

In an embodiment of the present invention, the core communicationsnetwork is maintained and a means is provided for edge devices, such asmedia gateways, to detect impending congestion in the core. Based onthis information, the edge devices can refuse new incoming connectionsto the media gateways to mitigate the congestion. This is calledConnection Admission Control (CAC), and traditional PSTNs rely on localswitches to perform this CAC function when the network is too busy toprocess a call. In this manner the gateways can maintain voice qualitywhile keeping the core fast and simple.

In an embodiment of the present invention, a carrier implements anInternet protocol (IP) voice tandem to interconnect conventional publicswitched telephone network (PSTN) switches. In order to provide thecarrier's traditional high-quality voice service while merging the PSTNand packet-based network technology, the carrier must employ a level ofQoS which provides low loss and a reasonable delay for real-timeprotocol (RTP) voice packets in the Internet protocol (IP) network core,and at the same time provide, as a minimum, best effort service fordata.

The IP voice tandem includes a media gateway, which periodicallytransmits high-priority control packets through a packet-switchednetwork, such as an IP network, to determine the least amount of timefor a packet to traverse the network. The media gateway transmitsreal-time protocol (RTP) bearer packets at a relatively lower priorityand measures the time it takes for the bearer packet to traverse thenetwork. The media gateway uses the results of these observations toinfer whether or not the network is congested. In one embodiment, themedia gateway calculates a delay threshold (Dt), above which the networkis congested. If the media gateway infers that the IP network iscongested, the gateway refuses connection requests until the congestionsubsides.

In an embodiment of the present invention, the delay threshold may bedetermined using a variety of methods. For example, in one embodiment,the media gateway calculates Dt by determining a mean control packetdelay; multiplying the mean control packet delay by a multiplier;determining a minimum control packet delay; and adding the result of themultiplying to said minimum control packet delay. The multiplier may bevaried for network tuning purposes.

In an embodiment of the present invention, the media gateway createscontrol packets with a timestamp, indicating when the packets were sentto the transmission queue. The media gateway then classifies thepackets, setting the priority to the highest priority in the network.For example, the media gateway may used Differentiated Services(DiffServ) and set various DS code points to classify the packets. Themedia gateway then transmits the control packets to the destination. Thedestination gateway receives the control packets and calculates thedelay threshold (Dt), above which the network is congested.

The source gateway also classifies and transmits RTP bearer packets. Thepriority assigned to the bearer packets is lower than that assigned tothe control packets. The destination media gateway receives the packetsand determines whether the delay associated with the bearer packetsexceeds Dt.

In one embodiment, the destination gateway performs Connection AdmissionControl (CAC). CAC may include refusing connection requests to nodesover links that the gateway has determined are congested. The refusalmay be indicated to the caller by a busy signal. CAC may also includeredirecting a call when the network is congested. For example, if acarrier utilizes an IP network for connecting calls from one regionaloffice of a customer to another, the carrier may simply redirect callsto the customer's IXC when the IP network is congested.

In an embodiment of the present invention, the clocks in the mediagateways need not be synchronized to calculate the delay and to detectcongestion. However, if the gateways must decode TDM voice calls, theywill need to be synchronized to a stratum 1-level timekeeping device.The stratum 1-level device may be an atomic or radio clock availableover the Internet or may be a global positioning system (GPS) satellite.

Embodiments of the present invention provide numerous advantages overconventional systems and methods for congestion detection and connectionadmission control. An embodiment of the present invention requires noexplicit support from the IP core routers. The routers are not requiredto maintain per-flow state or to respond to reservation requests. In anembodiment of the present invention, the conventional best-effortinfrastructure is maintained and mechanisms are added to the edgedevices to deliver high QoS. By avoiding any modifications to therouters, the operational and administrative overhead of implementing QoSmeasures is reduced substantially. Also, since changes to the core areunnecessary in an embodiment of the present invention, changes necessaryto manage a greater diversity of traffic are more easily designed andimplemented.

In an embodiment of the present invention, the determination of networkcongestion is based on delay rather than jitter, which is a moreaccurate threshold based on stochastic analysis. Also, in an embodimentof the present invention, edge devices employ binary endpoint admissioncontrol rather than a window mechanism as described. Also, no probing orfeedback is required, but control packets are sent constantly, all ofwhich result in a faster decision-making process. Unlike conventionalapproaches, the media gateway classifies control packets with a DiffServcode point that is a higher priority forwarding class than the RTPbearer packets requiring the QoS. Also, the method uses neithercongestion marking nor packet dropping.

Various network service providers may advantageously implement anembodiment of the present invention. For example, regional, national andinternational InterExchange Carriers (IXCs) often provide web-hostingservices. These providers may use an embodiment of the present inventionon their existing IP networks to derive additional income. Also,Competitive Access Providers (CACs), which provide alternativelong-distance service, may utilize an embodiment of the presentinvention to more successfully compete with the IXCs. In addition,Regional Bell Operating Companies (RBOCs) often provide Internet serviceor have alliances with Internet Service Providers (ISPs) and thereforeprovide a natural integration point from VoIP services. CompetitiveLocal Exchange Carriers (CLECs) have similar incentives to implement anembodiment of the present invention. In addition, ISPs attempting tobroaden their product offerings and thereby increase their revenuestreams may use an embodiment of the present invention to leverage theirexisting IP infrastructure.

Further details and advantages of the present invention are set forthbelow.

BRIEF DESCRIPTION OF THE FIGURES

These and other features, aspects, and advantages of the presentinvention are better understood when the following Detailed Descriptionis read with reference to the accompanying drawings, wherein:

FIG. 1 is a block diagram of the general environment for operation of anembodiment of the present invention.

FIG. 2 is a block diagram of an Internet protocol (IP) voice tandem inan embodiment of the present invention.

FIG. 3 is a block diagram of the IP voice tandem in communication with adifferentiated services-capable IP network in an embodiment of thepresent invention.

FIG. 4A is a block diagram of a media gateway with congestion detectionin an embodiment of the present invention.

FIG. 4B is a block diagram of the transmitter in the media gateway,illustrating three queues utilized in an embodiment of the presentinvention.

FIG. 4C is a block diagram of a queue within a DiffServ router.

FIG. 5 is a line graph illustrating the relationship between networkdelay and load in an embodiment of the present invention.

FIG. 6 is a line graph illustrating the relationship between networkdelay and time in an embodiment of the present invention.

FIG. 7 is a stacked bar graph illustrating the various components ofdelay for various types of packets in an embodiment of the presentinvention.

FIG. 8 is a flow chart illustrating the process of creating andtransmitting control packets in an embodiment of the present invention.

FIG. 9 is a flowchart illustrating the process of performing congestiondetection and connection admission control in an embodiment of thepresent invention.

DETAILED DESCRIPTION

Embodiments of the present invention provide systems and methods forutilizing one-way delay of packets transmitted through a communicationsnetwork to detect congestion in the communications network. In oneembodiment of the present invention, a communications service provider,referred to herein as a carrier, replaces conventional tandem switchesin a public switched telephone network with Internet protocol (IP)tandems. The IP tandem includes a media gateway, which performscongestion admission control for voice over IP (VoIP) communications.When delay in the communications network exceeds a delay threshold, themedia gateway may reject the communications request or may route therequest over an alternative channel.

In order to determine delay, a delay algorithm processor in the mediagateway first calculates a threshold delay based on the minimumpractical delay in the communications network. The threshold delay isthe amount of delay at which the processor infers that the network iscongested. The processor measures the minimum practical delay byutilizing a high-priority control packet. The processor then comparesthe calculated threshold delay with the actual delay experienced bybearer packets, which are transmitted using a lower priority than thepriority assigned to the control packets. If the bearer packet delayexceeds the threshold delay, the communications network is congested. Inone embodiment, the media gateway rejects communications request whenthe network is congested. In another embodiment, the media gatewayreroutes the calls over an alternative communications means.

In one embodiment of the present invention, a traditional carrierdeploys an IP voice tandem in a public switched telephone network(PSTN). The network also includes conventional 64 kb/s circuit switches.In order to deploy an IP voice tandem, the carrier either leverages anexisting IP core, which was built to support data services, or deploys anew IP core. The IP core may be multiuse and, if so, provides packetforwarding not only for the real-time protocol (RTP) packets containingthe time division multiplex (TDM) voice samples, but also providespacket forwarding for data, video, fax, or modem.

In an embodiment of the present invention, the carrier strives toprovide a quality of service (QoS) for voice calls equal or nearly equalto the quality conventionally provided by the PSTN. The conventionalcarriers have a long-standing reputation as the provider of choice whenit comes to quality and service. Therefore, the carrier does not want tobe perceived by customers as reducing voice quality or service byimplementing a packet-switched network.

In order to both provide a high level of voice quality and to beginmerging the circuit-switched PSTN with the packet-switched data network,the carrier must provide a level of QoS which provides low loss and areasonable delay for the RTP voice packets in the IP core, and at thesame time provide, as a minimum, best effort service for data. Inaddition to best effort service for data, the carrier may wish toprovide various levels of QoS for data, video, or fax.

To accomplish the necessary level of QoS for VoIP and maintain a simpleIP core, an embodiment of the present invention provides a means foredge devices, such as media gateways, hosts, or other devices, to detectimpending congestion in the core. Based on the observed state of thenetwork, the edge devices refuse or accept new incoming connectionrequests in order to manage the congestion on the network. Such aprocess is referred to as Connection Admission Control (CAC), andconventional PSTN carriers utilize local switches to perform this CACfunction when the network is too busy to process a call. By utilizingmedia gateways to perform CAC, the carrier can maintain voice qualitywhile keeping the IP core fast and simple.

Referring now to the Figures, FIG. 1 is a block diagram of the generalenvironment in which an embodiment of the present invention operates.When a caller wishes to place a call, the caller dials a directorynumber (DN) on a telephone 102 a. The DN identifies a destination, suchas telephone 102 b. Telephones 102 a,b are connected to local switches104 a,b via direct links 106 a, b, which may be, for example, localloops. A PSTN includes a plurality of local switches 104 a-h. PSTNtrunks 105 a-c interconnect these PSTN switches 104 a-h. The PSTN trunksutilize International Telegraph and Telephone Consultative Committee(CCITT, Comité Consultatif International Téléphonique et Télégraphique)Common Channel Signaling System no. 7 (CCS7). CCS7 is a standardprotocol suite used for communication with, and control of, telephonecentral office switches and other telecommunications network equipment.

In an embodiment of the present invention, the local switches 104 a-halso communicate with an Internet protocol (IP) voice tandem 108.Tandems interconnect other switches, such as local switches 104 a-h, toeach other and to other communication networks, such as Inter-exchangecarriers' (IXCs) networks (not shown). The tandem 108 conventionallylinks 20 or 30 local switches located within the same metropolitan areaor nearby cities. These local switches 104 a-h are connected tocustomers' telephone lines on what is called the line side of the switchand connected to either each other or to the tandem 108 on the trunkside of the switch.

When a customer connected to a local switch 104 a calls a customerconnected to a second local switch 104 b, the call may be directed fromthe calling party's local switch 104 a through the tandem 108 to thecalled party's local switch 104 b as shown in FIG. 1 by the dotted line.In a conventional PSTN network, when the network is too busy to completea call, the calling party's local switch 104 a performs connectionadmission control (CAC) by sending the originating terminal, telephone102 a, a busy signal. The caller knows this busy signal to mean to trythe call again later when the network may not be busy.

In an embodiment of the present invention, an IP voice tandem 108performs the CAC function. FIG. 2 is a block diagram of the IP voicetandem 108 in an embodiment of the present invention. The IP voicetandem 108 comprises Media Gateways 202 a-c, an IP network 205, one ormore softswitches 208, and one or more signaling gateways 212 as shownin FIG. 2. The IP network 205 portion of the IP voice tandem 108 is anetwork of interconnected routers running the IP protocol as illustratedin FIG. 3.

Conventionally, gateway is a generic term, describing a system forinternetworking. Gateways may include hardware, software, or acombination of both and may operate at various levels of the OpenSystems Interconnection (OSI) model. The media gateways 202 a-c in FIG.2 are devices or combinations of devices that terminate switched servicenetworks, packetize the data in IP packets, and deliver the packets toan IP-based packet network. They provide services to varioustransmission media. In general, media gateways may be connected to IPlinks terminating on routers, PSTN trunks 204 a-c terminating on PSTNswitches (not shown), primary rate integrated services digital network(ISDN) lines (not shown) terminating on ISDN devices (not shown),asynchronous transfer mode (ATM) links (not shown) terminating on ATMswitches (not shown), as well as other types of transmission media.

Media gateway 202 a performs a switching function and thus may switchvoice calls from a PSTN trunk 204 a to an IP network 205. In theembodiment shown in FIG. 2, 64 kb/sμ law encoded time divisionmultiplexed (TDM) voice calls enter the media gateway 202 a over thePSTN trunk 204 a and are switched over an IP link 206 a to the IPnetwork 205 in the form of a Real Time Protocol (RTP) packet. TDM is atype of multiplexing where two or more data and/or voice channels aretransmitted simultaneously over one communications link by interleavingthe signals. Each channel allocates a different time interval, and thetransmission includes a synchronizing signal to distinguish the variouschannels within the transmission. RTP is an Internet Engineering TaskForce (IETF) standard for providing end-to-end network transportsuitable for transmitting real-time data, such as audio, video, orsimulation data, over multicast or unicast network services and isdefined in RFC1889.

The RTP packet is forwarded over the IP network 205 to another mediagateway 202 c on the other side of the IP network 205 via IP link 206 c.This second media gateway 206 c receives the RTP packet from the IPnetwork 205 and converts it back to a 64 kb/sμ law encoded TDM voicecall transmitted over another PSTN trunk 204 c. The call then proceedsto its ultimate destination over the PSTN network (not shown).

The media gateway 202 a-c communicates with a softswitch 208, which isalso known as a call agent, or media gateway controller, via IP network205 and link 210. The softswitch 208 contains routing information. Thisrouting information is configured by a network management system (notshown) and is used by the softswitch 208 to route incoming calls frommedia gateway 202 a to media gateway 202 c across the IP network 205.The IP network 205 in general will be a multiuse IP network which willprovide packet forwarding not only for the RTP packets containing theTDM voice samples from the media gateways 202 a-c, but may also providepacket forwarding for other applications such as data, video, fax, andmodem.

The signaling gateway 212 interfaces the IP network via link 214 andwith the CCS7 network (not shown) via a CCS7 link 216. The signalinggateway 212 acts as a CCS7 Signaling Point (SP) for the IP voice tandem108. The CCS7 signaling gateway 212 receives the call from itsoriginating local switch in the PSTN network and directs the call to itsterminating local switch as illustrated in FIG. 1.

In one embodiment of the present invention, the IP network 205 comprisesdifferentiated services-capable routers. FIG. 3 is a block diagram ofthe IP voice tandem 108, and its media gateways 202 a-c in communicationwith a differentiated services-capable IP network 205 via links 206 a-c.

Differentiated Services (DiffServ) is a method of providing a limitedform of quality-of-service (QoS) across a router network, such as theone shown in FIG. 3. In the DiffServ model, packets entering a networkdomain are classified into behavior aggregates (BA) and marked with aDiffServ code point (DS code point) according to their requirements forPer Hop Behavior (PHB). The PHB is a forwarding behavior that representsqueuing and servicing disciplines in the routers. PHBs provide a meansof allocating bandwidth and buffers according to the relativerequirements of the packets being transferred across the network.Packets are grouped into classifications, called behavior aggregates(BA), and all packets in a classification receive the same treatment.

In the embodiment shown, calls originating in the PSTN networks 302 a-carrive at the media gateways 202 a-c via PSTN trunks 204 a-c. The mediagateways 202 a-c forward the calls to DiffServ routers 304 a-c, wherethey are routed via IP links 306 a-c though a DiffServ-capable IPnetwork 308. A router is a physical device that joins multiple networkstogether and operates at the network layer (three) of the Open SystemsInterconnection (OSI) model. The router includes a routing table, whichthe router uses to determine how packets are to be forwarded.

FIG. 4 is a block diagram of a media gateway 202 with congestiondetection in an embodiment of the present invention. The media gateway202 includes the functionality of a conventional media gateway, which isimplemented by a media gateway processor 402. The media gatewayprocessor 402 receives bearer traffic arriving from PSTN trunks or fromother sources such as media gateways in other domains, private branchexchanges, primary rate ISDN trunks, or even individual telephone lines404. The media gateway processor 402 communicates with the signalinggateway 212 to establish new calls across the IP network (not shown).The media gateway processor 402 also timestamps RTP packets and forwardsthem into the network. The media gateway processor also includes acongestion state table 403. The table 403 stores the current or recentcongestion state of the network. The media gateway processor 402utilizes this information in performing CAC.

In order to implement congestion detection according to the presentinvention, the media gateway 402 in an embodiment of the presentinvention also includes a classifier marker 408, a transmitter (XMT)410, a control packet generator 412, and a timestamp clock 414. Thecontrol packet generator 412 adds a timestamp to packets, using thetimestamp clock 414, and forwards the packets into the IP network (noshown). The classifier marker 408 classifies and marks both the controlpackets and the RTP bearer packets with a DiffServ code point.

The media gateway 202 also includes a receiver (RCV) 418. When thereceiver 418 receives packets, it forwards the packets to the mediagateway processor 402. The receiver 418 also forwards the packets or thetimestamp information contained in the packet headers to the delayalgorithm processor 420. The delay algorithm processor 420 utilizes thetimestamp information contained in the headers to determine whether toadmit or deny new calls and forwards this information to the mediagateway processor 402. As is described in greater detail with referenceto FIG. 9, if the delay algorithm processor 420 instructs the mediagateway processor to deny new calls, the media gateway processor 402refuses new call requests from the signaling gateway 212. If thedecision is to admit new calls the media gateway processor 402 beginsadmitting new calls until the delay algorithm processor 420 signals thatnew calls should be denied.

In an embodiment of the present invention, it is necessary for thetimestamp clock 414 in each media gateway 202 to be traceable back tothe same stratum I clock (not shown) because the gateways are switchingTDM voice calls, which require highly accurate synchronization. Theclock may also be used to measure one-way delay between two gateways. Astratum 1 clock is an extremely accurate timekeeping device, such as anatomic or radio clock. Primary stratum 1-level devices synchronize otherlower strata timekeeping devices via a hierarchical subnet, using radio,satellite, and/or modem. In addition, a lower strata timekeeping devicemay be kept accurate using a network access card, utilizing network timeprotocol (NTP) or digital time synchronization service (DTSS). NTP is aprotocol, which is capable of synchronizing distributed clocks withinmilliseconds to stratum l-level devices accessible on the Internet. Anembodiment of the present invention may use other stratum 1-leveltimekeeping devices, such as Loran-C and GPS receivers.

An embodiment of the present invention utilizes one-way delay of packetstraversing a network between edge devices to determine networkcongestion. Delay refers to the time it takes a packet to move from onepoint on the network to another. Delay causes echo, the reflection ofthe speaker's voice from the destination telephone equipment back to thesource telephone, and talker overlap, when one caller is speaking at thesame time as the other caller. Computer networking delay isconventionally categorized as processing delay, queuing delay,transmission delay, and propagation delay. Processing delay, also calledaccumulation or algorithmic delay, is the amount of time required by therouter to process the packet header to determine a route and any othertasks required on each packet, such as error checks, before the packetis directed to an output queue. All packets experience this processingdelay, and the processing delay is very similar regardless of packetsize.

Queuing delay is the amount of time a packet waits in a queue beforearriving at the head of the queue and transmission onto the link begins.Propagation delay is the amount of time required to propagate a bit fromone end of a link to the other end of the link. The propagation delaydepends on the length of the link and the type of medium, such astwisted pair copper, single mode fiber, microwave radio frequency (RF),etc. Transmission delay refers to the amount of time it takes totransmit all of the bits in a packet from the output queue into thetransmission link. A cumulative delay above 150-200 milliseconds (ms) isconsidered generally unacceptable. For toll-quality phone calls, delayshould be less than 100 ms.

Other causes can reduce the quality of VoIP service. For example, jittercan cause the sound of voices participating in a VoIP call to soundunnatural. Jitter is caused by variations in the timing of voicepackets. Voice packets are generated by codecs at orderly, periodic timeintervals. The number of bytes in a packet and the time interval betweenpackets are determined by the particular codec that is used. Over aconverged network, voice packets are interleaved with data packets,causing the normally orderly voice packets to arrive at disorderlyintervals, resulting in jitter.

Also, the IP network may drop voice packets due to network congestion.When data packets are dropped, the sending system can simply retransmitthe lost packets. Unfortunately, because of the time necessary toretransmit packets, voice packets cannot be retransmitted. Therefore,carriers strive to minimize the number of dropped packets. InConventional IP phone systems, packet loss in excess of 2.5-5% isunacceptable.

FIG. 4B is a block diagram of the transmitter 410 of the media gateway202. In an embodiment of the present invention, the transmitter 410 iscapable of utilizing a plurality of queues, which are each assigned arelative priority level. In the embodiment shown, the transmitter 410includes two queues. The highest priority queue is the EF1 queue 422. Inan embodiment of the present invention, the EF1 queue 422 processes andtransmits the control packets. The transmitter 410 also includes an EF2queue 424. The EF2 queue 424 processes RTP bearer packets and has arelative priority lower than that assigned to the EF1 queue 422.

FIG. 4C is a block diagram of the queue within a DiffServ router 304. Inaddition to the EF1 426 and EF2 428 queues, which process data from theMedia Gateway transmitter 410, the DiffServ router 304 also includes aBE (Best Effort) queue 430. Data packets enter the IP network via aseparate interface on the DiffServ router 304 and are placed in the BEqueue 430. The BE queue 430 has the lowest relative priority of thethree queues.

To clearly understand the systems and methods of the present invention,it is necessary to understand the relationship between the load on anetwork and the delay encountered by packets traversing the network.FIG. 5 is a line graph illustrating the relationship between networkdelay and network load. In the graph, delay in seconds 502 is plottedversus load 504 as a percentage of capacity of a link between the sourceand the destination. Delay in a network remains relatively constant overa broad range of load percentage. However, as the network reachescongestion, the delay increases sharply. This is illustrated by the“knee” curve 506. Beyond the point of congestion 506, the delaycontinues to increase until the network will accept no additional load508.

FIG. 6 is a line graph illustrating the relationship between networkdelay 602 and time 604 in a simplified network. In a simplified network,where there is only one queue, one constant bit rate source, and onedestination, the one-way delay across the network remains constant untilthe capacity of the link between the output queue and the destination isexceeded 606. As soon as the capacity of this link is exceeded the queuebegins to increase in length and the delay begins to increase andcontinues to increase until the queue is full and begins droppingpackets 608. Beyond this point 608 the delay oscillates between twofixed points.

The situation becomes progressively more complicated as routers andsources are added to the network and statistical methods and simulationsmust be used to analyze the situation. However, the basic idea ofdetecting the knee of the curve illustrated in FIGS. 5 and 6 stillapplies. In an embodiment of the present invention, when impendingcongestion is suggested by this increase in delay 506, 606, the mediagateway (202) begins refusing calls to prevent further congestion and toallow the congestion to subside before beginning to admit more calls.

As illustrated in FIG. 6, in the simplified model with a single sourceand destination, and a single router and first-in-first-out (FIFO)output queue, when the link between the output queue and the destinationbecomes overloaded 606, the queue grows until packets are discarded 608.Up until the link becomes overloaded 606, the queue will remain emptyand the delay across the network will be the minimum delay. When we addmultiple queues, having various relative levels of priority, to thesimplified model the analysis becomes more complex.

If the link is not congested, that is, there is sufficient bandwidth totransfer all of the packets arriving at the router, and if a data packetarrives at the best-effort queue just the instant before the arrival ofa control packet into the high-priority DiffServ queue, and there are nobearer packets in the low-priority DiffServ queue, the data packet willbegin transmitting. The control packet in the high-priority queue mustwait for the data packet in the best-effort queue to finish transmittingbefore the control packet can be transmitted. Waiting for the datapacket causes a slight delay to the control packet so that its one-waydelay is slightly longer than the minimum.

By the same reasoning, the bearer packets will experience the samephenomena if a data packet arrives into the best-effort queue just theinstant before the arrival of a bearer packet into the low-priorityqueue, and if there are no control packets in the high-priority queue.This delay is a component of queuing delay. A similar delay occurs whena control packet must wait in the high-priority queue until a bearerpacket is transmitted. These types of delays occur even if the linkbetween the router and the destination are not congested and in effectadd a noise component or uncertainty to the delay capacity curve shownin FIG. 6. This uncertainty can be analyzed using stochastic methods todetermine a threshold that will give a high probability of making thecorrect choice to either admit or reject new calls.

FIG. 7 is a stacked bar graph illustrating the various components ofdelay for a control packet 702 and a bearer packet 704 in an embodimentof the present invention. The propagation delay, processing delay andtransmission delay make up the component D_(min) 706, 708. D_(min) isthe minimum delay across the network and is experienced by all controlpackets and bearer packets.

As illustrated in FIG. 4C, EF1 packets are control packets arriving inthe high-priority DiffServ queue (426). EF2 packets are bearer packetsarriving in a low-priority DiffServ queue (428). BE packets are datapackets arriving in a best-effort queue (430): The queuing delay can bebroken into several components. D_(BE) 710, 712 is the delay both EF1and EF2 packets experience when they have to wait on a BE data packet totransmit and the output link is not congested by too many calls.D_(EF2/EF1) 714 is the delay experienced by an EF1 control packet whenan EF2 bearer packet arrives just an instant earlier than the controlpacket and the control packet must wait for the bearer packet to betransmitted before beginning to transmit. D_(EF2/EF2) 716 is the delayexperienced by two or more EF2 packets arriving from different sourcesinto the output queue at the same time. D_(EF1/EF1) 718 is the delayexperienced by two or more EF1 packets arriving from different sourcesinto the output queue at the same time. D_(EF1/EF2) 720 is the delayexperienced by an EF2 bearer packet when it must wait for an EF1 packetto be transmitted and there is not congestion on the output link.

For purposes of an embodiment of the present invention, the mostimportant component is the D_(Q) component 722, which is the queuingdelay due to there being more calls than can be supported by the outputlink. This is the component that tells us of the congestion state of thenetwork. In fact the D_(Q) component 722 remains zero until the capacityof the output link is exceeded by more calls than can be supported inthe EF2 bearer queue. The D_(Q) component 722 has the samecharacteristic delay capacity curve as that shown in FIG. 6. The otherqueuing delay components add a noise component or uncertainty to thecurve.

As more sources and more routers are added to the network, the queuingdelay components due to simultaneous arrivals can be considered randomvariables, and the probability distribution functions can beapproximated as Gaussian due to the Central Limit Theorem. The CentralLimit Theorem states that the sum of a large number of independentobservations from the same distribution has, under certain generalconditions, an approximate normal distribution. A normal or Gaussiandistribution is usually represented by a bell-shaped curve symmetricalabout the mean.

Based on this analysis, a probability of a correct choice to eitheradmit or deny new calls into the network can be derived. An embodimentof the present invention uses this analysis to implement a mechanism toenable detection of congestion and make decisions as to when to stopadmitting new calls and when to begin admitting new calls into thenetwork.

FIG. 8 is a flow chart illustrating the process a media gateway (202) asillustrated in FIG. 4 implements to create and transmit control packetsin an embodiment of the present invention. The control packet generator(412) creates a control packet 802 and timestamps the packet afterobtaining the time from timestamp clock (414) 804. The classifier marker408 then classifies or sets the priority of the control packet 806. Theclassifier marker (408) uses a DiffServ code point of the highestpossible forwarding equivalence class (FEC), EF1 in FIG. 7. Theclassifier marker (408) marks no other traffic with the EF1 code pointso that these control packets experience the minimum delay possibleacross the network. The transmitter (4 10) then transmits the controlpackets across the network to other media gateways (not shown) 808. Inorder to determine the congestion present in the network, the mediagateway (202) creates and transmits control packets periodically. In theprocess shown in FIG. 8, the media gateway waits some period of time 810and then repeats steps 802-810.

As with conventional systems, the media gateway (202) also forwardsbearer traffic across the network. In an embodiment of the presentinvention, the media gateway sends the bearer packets with a DS codepoint with the next to highest possible forwarding class, EF2. Thebearer packets, which are RTP packets, also include a source timestamp,and the delay algorithm processor (420) uses the timestamp to measurethe one-way delay experienced by the bearer traffic.

FIG. 9 is a flowchart illustrating the process of performing congestiondetection and connection admission control in an embodiment of thepresent invention. In an embodiment of the present invention, the mediagateway (202) attempts to determine the point at which a communicationlink becomes congested. By comparing the minimum delay experienced bythe control packets in the EF1 queue with the delay experience by thebearer traffic in the EF2 queue, the media gateway (202) detects thepoint at which the link becomes congested, and the congestion state ofthe network can be inferred.

As shown in FIG. 8, in one embodiment of the present invention, thesource media gateway (202) timestamps the control packets with thecurrent time and transmits the control packets to the destination mediagateway (not shown), which records the arrival time. In embodiment ofthe present invention, the destination media gateway includes thecomponents of the source media gateway (202) as illustrated in FIG. 4,and therefore, all references to both the source and destination mediagateway are made with reference to FIG. 4.

As shown in FIG. 9, two sub-processes occur simultaneously and inparallel, the process of calculating the delay threshold Dt based on thecontrol packets, 902-911, and the process of calculating bearer packetdelay Db, 912-922. According to the process shown in FIG. 9, the mediagateway receiver (418) receives a control packet from a source mediagateway (202), gateway A 902. When the media gateway receiver (418)receives a control packet, the media gateway processor (402) utilizesthe timestamp clock (414) to record the arrival time of the packet 904.For purposes of the following description, Tcs denotes the timestamp ofthe control packet at the source media gateway (202). Tcd denotes thearrival time of the control packet at the destination.

The sub-process 902-911 is repeated as the media gateways (202) repeatthe process of sending and receiving control packets. If the process hasbeen repeated n times 908, information regarding the oldest packet, thefirst packet received is dropped 907. The most recent record of Dc isdenoted as Dc(0), the next most recent record of Dc as Dc(1) and so on,so that the n control packet delays are given by:Dc=[Dc(0), Dc(1), Dc(2), . . . Dc(n-1)   [Equation ]

Using the arrival and departure time of a control packet, the delayalgorithm processor (420) can calculate the delay of the control packet,Dc, as follows 906:Dc=Tcd−Tcs   [Equation 2]

In an embodiment of the present invention, the delay algorithm processor(420) next determines the threshold delay (Dt) for the link between thetwo media gateways (202) 910. In one embodiment, the delay algorithmprocessor (420) determines the delay of the p_(th) percentile of thecontrol delay array, Dc, which is designated Dp. The processor (420)first determines the minimum of the control delay array, Dc, designatedDmin. Dmin represents the minimum delay across the network. Dp issomewhere near the maximum of the delay across the network but not themaximum. The variable, p, is tunable based on the actual networkimplementation. For example, in one embodiment, p is 95%. The thresholddelay, Dt is given by the following formula:Dt=v*(Dp−Dmin)+Dmin   [Equation 3]

Where v is a tunable multiplier in the range from one to two (1≦v≦2),and:Dp=pth percentile(Dc)   [Equation 4]Dmin=min(Dc)   [Equation 5]

In another embodiment of the present invention, Dt is determined basedon the mean of the control delay array, Dc, which designated as Dμ. Thedelay threshold is given by the following formula:Dt=u*(Dμ−Dmin)+Dmin   [Equation 6]

Where u is a tunable multiplier in the range from one to four, (1≦u≦4);Dmin is determined as described above. The value of Dt is stored in thecongestion state table (403) 911.

RTP bearer packets are processed in a similar manner. However, bearerpackets are transmitted at a lower priority relative to the controlpackets. The source media gateway (202) timestamps bearer packets withthe current time and transmits the packets to the destination. Thedestination media gateway (202) receives the bearer packet once it hastraversed the IP network 912. The destination gateway (202) records thearrival time to calculate delay 914.

As with Dc, an embodiment of the present invention maintains the last mrecords of Db 916, 917, which are given by:Db=[Db(0), Db(1), Db(2), . . . Db(m-1)   [Equation 7]

The number of elements in Db, which is given by m, is tunable but wouldnormally be in the range of one to five (1≦m≦5).

The destination gateway (202) calculates delay by subtracting the sourcetimestamp from the arrival time 918. Tbs denotes the timestamp of thebearer packet at the source; Tbd denotes the arrival time of the bearerpacket at the destination. Therefore, the delay of the RTP bearerpacket, Db is calculated as follows:Db=Thd−Ths   [Equation 8]

The source and destination clocks need not be absolutely synchronized todetermine delay, i.e., at any instant in time, the clocks do not have toread the same. However, they must maintain relative synchronization overtime, i.e., their clocks must maintain the same relative distance overtime. To state this mathematically, If Ts(t₀) is the time on the sourceat time instant zero and Td(t₀) is the time on the destination at timeinstant zero, then it is not necessary for Ts(t₀) =Td(t₀). However ifTs(t₁) is the time on the source at some time instant one, and Td(t₁) isthe time on the destination at time instant one, then the following mustbe true for all t_(n):Ts(t ₁)−Ts(t ₀)=Td(t ₁)−Td(t ₀)   [Equation 9]

Thus the values of Dc and Db can actually be negative. This is not aproblem since we are only interested in the relative delay differencebetween Dc and Db, and any offset in their clocks is subtracted out.

In one embodiment of the present invention, once the destination gatewayhas calculated Db, the value is stored in the congestion state table(403) 920 for later use. The congestion state is then determined 922. Inanother embodiment, the values of Dt and Db are first compared, and aflag is stored in the table (403) denoting whether or not to accept callrequests for a destination.

FIG. 10 is a flowchart illustrating the handling of a communicationsrequest in an embodiment of the present invention. The media gatewayreceives a request to create a call to a specific destination 1002. Thesource media gateway (202) retrieves Db and Dt from the congestion statetable 403. If all of the elements of Db exceed Dt then congestion isimplied and the media gateways (202) at both ends of a communicationshould stop admitting new calls until none of the elements of Db exceedDt. If Db>Dt, the source gateway (202) rejects the request 1008. IfDt≦Db, the request is accepted 1010. In another embodiment, thecongestion state table (403) includes a flag for each destinationgateway (202) on the network, denoting whether or not connectionrequests to the destination should be accepted. This flag is updatedperiodically.

An embodiment of the present invention includes a computer-readablemedium, having computer-readable instructions for performing congestiondetection. The computer-readable medium may also include program codefor performing connection admission control. A computer-readable mediumincludes an electronic, optical, magnetic, or other storage ortransmission device capable of providing a processor, such as theprocessor in a web server, with computer-readable instructions. Examplesof such media include, but are not limited to, a floppy disk, CD-ROM,magnetic disk, memory chip, or any other medium from which a computerprocessor can read. Also, various other forms of computer-readable mediamay transmit or carry instructions to a computer, including a router,private or public network, or other transmission device or channel.

The foregoing description of the preferred embodiments of the inventionhas been presented only for the purpose of illustration and descriptionand is not intended to be exhaustive or to limit the invention to theprecise forms disclosed. Numerous modifications and adaptations thereofwill be apparent to those skilled in the art without departing from thespirit and scope of the present invention.

1. A method for detecting congestion in a communications networkcomprising: (a) determining a control packet transmission duration for acontrol packet, said control packet having a control packet transmissionpriority; (b) determining a bearer packet transmission duration for abearer packet, said bearer packet having a bearer packet transmissionpriority, wherein said bearer packet transmission priority is lower thansaid control packet transmission priority; (c) calculating a delay in atransmission of said bearer packet; and (d) comparing said delay to athreshold delay.
 2. The method of claim 1, further comprising: (e)rejecting a communication request when said delay exceeds said thresholddelay.
 3. The method of claim 1, further comprising: (e) redirecting acommunication request when said delay exceeds said threshold delay. 4.The method of claim 1, further comprising calculating said thresholddelay.
 5. The method of claim 1, wherein said calculating of saidthreshold delay comprises: determining a mean control packet delay;multiplying said mean control packet delay by a multiplier; determininga minimum control packet delay; and adding the result of saidmultiplying to said minimum control packet delay.
 6. The method of claim1, wherein said calculating comprises: determining a control packetdelay for a specified percentile of all bearer packets; multiplying saidcontrol packet delay by a multiplier; determining a minimum controlpacket delay; and adding the result of said multiplying to said minimumcontrol packet delay.
 7. The method of claim 1, further comprisingtransmitting said control packet.
 8. The method of claim 1, furthercomprising creating said control packet.
 9. The method of claim 1,further comprising setting said control packet transmission priority.10. The method of claim 1, further comprising transmitting said bearerpacket.
 11. The method of claim 1, further comprising setting saidbearer packet transmission priority.
 12. The method of claim 1, furthercomprising repeating steps a-c.
 13. A method for detecting congestion ina communications network comprising: (a) receiving a control packet,having a control packet transmission priority and a control packetsource timestamp; (b) recording a control packet time received; (c)determining a control packet transmission duration by subtracting saidcontrol packet source timestamp from said control packet time received;(d) receiving a bearer packet, having a bearer packet transmissionpriority and a bearer packet source timestamp, wherein said bearerpacket transmission priority is lower than said control packettransmission priority. (e) recording a bearer packet time received; (f)determining a bearer packet transmission duration by subtracting saidbearer packet source timestamp from said bearer packet time received;(g) calculating a queuing delay encountered by said bearer packet bysubtracting said control packet transmission duration from said bearerpacket transmission duration; and (h) comparing said queuing delay to athreshold delay.
 14. The method of claim 1, further comprising: (i)rejecting a communication request when said queuing delay exceeds saidthreshold delay.
 15. The method of claim 1, further comprising: (i)redirecting a communication request when said queuing delay exceeds saidthreshold delay.
 16. The method of claim 13, further comprisingcalculating said threshold delay.
 17. A computer-readable medium onwhich is encoded computer program code for detecting congestion in acommunications network comprising: (a) computer program code fordetermining a control packet transmission duration for a control packet,said control packet having a control packet transmission priority; (b)computer program code for determining a bearer packet transmissionduration for a bearer packet, said bearer packet having a bearer packettransmission priority, wherein said bearer packet transmission priorityis lower than said control packet transmission priority; (c) computerprogram code for calculating a delay in a transmission of said bearerpacket; and (d) computer program code for comparing said delay to athreshold delay.
 18. The computer-readable medium of claim 17, furthercomprising: (e) computer program code for rejecting a communicationrequest when said delay exceeds said threshold delay.
 19. Thecomputer-readable medium of claim 17, further comprising: (e) computerprogram code for redirecting a communication request when said delayexceeds said threshold delay.
 20. The computer-readable medium of claim17, further comprising program code for calculating said thresholddelay.
 21. The computer-readable medium of claim 20, wherein saidprogram code for calculating said threshold delay comprises: programcode for determining a mean control packet delay; program code formultiplying said mean control packet delay by a multiplier; program codefor determining a minimum control packet delay; and program code foradding the result of said multiplying to said minimum control packetdelay.
 22. The computer-readable medium of claim 20, wherein saidprogram code for calculating said threshold delay comprises: programcode for determining a control packet delay for a specified percentileof all bearer packets; program code for multiplying said control packetdelay by a multiplier; program code for determining a minimum controlpacket delay; and program code for adding the result of said multiplyingto said minimum control packet delay.
 23. The computer-readable mediumof claim 17, further comprising program code for transmitting saidcontrol packet.
 24. The computer-readable medium of claim 17, furthercomprising program code for creating said control packet.
 25. Thecomputer-readable medium of claim 17, further comprising program codefor setting said control packet transmission priority.
 26. Thecomputer-readable medium of claim 17, further comprising program codefor transmitting said bearer packet.
 27. The computer-readable medium ofclaim 17, further comprising program code for setting said bearer packettransmission priority.
 28. The computer-readable medium of claim 17,further comprising program code for repeating steps a-c.
 29. Acomputer-readable medium on which is encoded computer program code fordetecting congestion in a communications network comprising: (a) programcode for receiving a control packet, having a control packettransmission priority and a control packet source timestamp; (b) programcode for recording a control packet time received; (c) program code fordetermining a control packet transmission duration by subtracting saidcontrol packet source timestamp from said control packet time received;(d) program code for receiving a bearer packet, having a bearer packettransmission priority and a bearer packet source timestamp, wherein saidbearer packet transmission priority is lower than said control packettransmission priority. (e) program code for recording a bearer packettime received; (f) program code for determining a bearer packettransmission duration by subtracting said bearer packet source timestampfrom said bearer packet time received; (g) program code for calculatinga queuing delay encountered by said bearer packet by subtracting saidcontrol packet transmission duration from said bearer packettransmission duration; and (h) program code for comparing said queuingdelay to a threshold delay.
 30. The computer-readable medium of claim29, further comprising program code for: (i) rejecting a communicationrequest when said queuing delay exceeds said threshold delay.
 31. Thecomputer-readable medium of claim 29, further comprising program codefor: (i) redirecting a communication request when said queuing delayexceeds said threshold delay.
 32. The computer-readable medium of claim29, farther comprising program code for calculating said thresholddelay.
 33. A system for detecting congestion in a communications networkcomprising: a first media gateway in communication with saidcommunications network, wherein said first media gateway comprises: atimestamp clock, a control packet generator in communication with saidtimestamp clock, and a classifier marker in communication with saidcontrol packet generator; a second media gateway in communication withsaid communications network, wherein said second media gatewaycomprises: a system clock, and a delay calculator in communication withsaid system clock.
 34. The system of claim 33, wherein said timestampclock comprises a first stratum-1-classified signal receiver time. 35.The system of claim 33, wherein said system clock comprises a secondstratum-1-classified signal receiver time
 36. The system of claim 33,wherein said communications network comprises an Internet protocol (IP)network.
 37. The system of claim 22, wherein said first media gatewaycomprises an IP voice tandem.
 38. The system of claim 22, wherein saidsecond media gateway comprises an IP voice tandem.
 39. The system ofclaim 33, wherein said first stratum-1-classified signal receiver timecomprises a network access card.
 40. The system of claim 33, whereinsaid first stratum-1-classified signal receiver time comprises a globalpositioning system receiver.
 41. The system of claim 33, wherein saidsecond stratum-1-classified signal receiver time comprises a networkaccess card.
 42. The system of claim 33, wherein said secondstratum-l-classified signal receiver time comprises a global positioningsystem receiver.
 43. The system of claim 33, wherein said classifiermarker comprises a differentiated services (DiffServ) classifier marker.44. The system of claim 33, wherein said classifier marker comprises: acontrol packet queue; having a first transmission priority; and a bearerpacket queue, having a second transmission priority, wherein said firsttransmission priority is higher than said second transmission priority.45. The system of claim 33, further comprising a connection admissioncontroller in communication with said delay calculator.